1. Statement of the Technical Field
The present invention relates to enterprise server interprocess communications and more particularly to internal queued direct input/output (QDIO).
2. Description of the Related Art
For twenty-six years, the parallel channel fulfilled the role as the sole enterprise server attachment interface. At its introduction, the parallel channel supported a maximum bandwidth of 2.5 Megabytes (MB) per second which ultimately grew to 4.5 MB/second. In the parallel input/output (I/O) infrastructure, a proprietary controller functioned as a wire concentrator for dumb terminals attached to the interface through coaxial cable links. As the parallel I/O infrastructure reached its limitations, however, in its ability to support large system images, high availability, flexible connectivity, configuration management, and performance, IBM Corporation of Armonk, New York introduced ESCON™ technology as a new I/O interconnection architecture supporting a new topology for high-speed, long distance data exchange.
When IBM Corporation first introduced ESCON, the topology of the enterprise server supported data center had begun to change, though access to the underlying network remained unchanged. Specifically, front end processors, interconnect controllers, and similar devices having parallel I/O or ESCON channel attachment interfaces remained the only connectivity options available when accessing enterprise server resources with outbound and inbound network traffic. In consequence, it was believed that providing an industry-standard open interface would simplify the data center topology and begin to lessen the number of devices required between the enterprise server and the end users, while reducing complexity and the total cost of computing. In response, IBM Corporation developed the Open Systems Adapter™ (OSA).
In consequence of the development of OSA, TCP/IP networks and applications began to proliferate in the late 1990s as the enterprise server now could be directly connected to the TCP/IP network through the OSA attachment interface. Moreover, the expense and complexity associated with the use of parallel and ESCON-attached interconnect controllers and routers, as well as front end processors, now could be lessened with TCP/IP traffic and some SNA traffic flowing directly into the enterprise server through the OSA attachment interface. As a result, enterprise servers now could be incorporated within heterogeneous, multi-vendor networking infrastructures.
Recent versions of the OSA attachment interface support queued direct I/O (QDIO). QDIO is an important channel control unit design that dramatically improves data throughput by allowing data to pass directly to enterprise server memory. With QDIO, the number of I/O interruptions can be minimized. Specifically, in the QDIO architecture, a common storage area can be maintained for memory-to-memory communication, reducing system overhead and improving performance. In consequence, read or write channel programs are not necessary for data exchange. Furthermore, I/O interrupts need not be handled for write processing. Similarly, for read processing, the number of I/O interrupts can be minimized. Notably, in the QDIO architecture a Direct Memory Access (DMA) protocol can be used to transfer all network data between the two processing functions in a highly efficient manner while maintaining the inherent reliability and data integrity of the enterprise server I/O subsystem architecture.
Typically, queues in the QDIO architecture include one-hundred and twenty-eight entries, each entry having a storage block address list (SBAL). Ordinarily, an SBAL represents a single, complete read or write I/O operation and includes a fixed number of entries, typically sixteen. Each entry, in turn can be referred to as a storage list entry and can provide its length and a pointer to a memory page or frame of real storage. The page, typically a four kilobyte page, can include one or more data packets, each packet having a protocol header and associated data. Thus, each SBAL can include sixty-four kilobytes of real storage.
Notably, the QDIO architecture can support internal interprocess communications between multiple logical partitions. As is well-known in the art, a logical partition (LPAR) is the division of an enterprise server's processors, memory, and storage into multiple sets of resources so that each set of resources can be operated independently with its own operating system instance and applications. The number of LPARs that can be created typically can depend upon the processor model of the enterprise server and the enterprise server's available resources. Multiple LPARs can be configured within an enterprise server for varying purposes such as database operations, client/server operations or to separate test and production environments. In any event, using an internal implementation of the QDIO architecture, referred to as “iQDIO”, each LPAR can communicate with other LPARs as if the other LPAR were physically positioned within a separate enterprise server.
As an example, using an OSA adapter configured with the iQDIO architecture, Internet protocol (IP) based data traffic can flow between LPARs within the same enterprise server. More particularly, the central processor of the iQDIO architecture can examine the IP address of each outbound packet and, if the destination IP address is associated with one of the LPARs residing in the same enterprise server as defined in an address table, the outbound packet can be forwarded directly to the destination LPAR. Notably, the iQDIO architecture can provide better performance and higher availability between LPARs since an external network is not required to transfer outbound IP packets.
In a conventional enterprise server which has been configured for LPAR-to-LPAR interprocess communications using the iQDIO architecture, each LPAR can have associated therewith a channel path ID (CHPID). Typical enterprise servers can accommodate a discrete number of distinct CHPIDs, typically four (4). Using the iQDIO architecture, the central processor and the enterprise server can share data queues, as compared to the conventional use of QDIO technology in which the central processor shares data queues with the I/O adapter. In this way, data packets can be sent and received in each LPAR referenced by particular CHPIDs.
Ordinarily, in order for a given LPAR to gain connectivity to another LPAR within the same enterprise server, the LPAR must be configured to use the same CHPID as the other LPAR. In particular, an iQDIO logical device can be configured within each LPAR. The iQDIO logical device, often referred to as a “subchannel address”, can include an inbound (receive) queue, and multiple outbound (send) queues, allowing the logical device to both send and receive data simultaneously through the iQDIO hardware.
In order for the target LPAR to receive data packets transmitted by a sending LPAR, the central processor can queue SBALs in the inbound queue of the target LPAR, thereby making those read buffers available for use by the iQDIO hardware. Normally, sending LPARs use a signal adapter instruction (SIGA) to transmit data packets to a target LPAR. Responsive to receiving the SIGA instruction, the iQDIO hardware can locate the target LPAR and can move the outbound data packets from SBALs in the outbound queue of the sending LPAR to the previously queued SBALs of the inbound queue of the target LPAR. Once inbound data has been forwarded to the target LPAR, the iQDIO hardware can complete the operation by marking those queued SBALs as “complete”.
Importantly, as one-skilled in the art will recognize, the SIGA instruction of the iQDIO architecture is synchronous in nature. Specifically, when a SIGA instruction issues, the entire I/O operation can be performed by the same processor which executed the SIGA instruction. When a subsequent instruction gains control, the execution of the SIGA instruction can be assumed to have completed. If the execution of the SIGA instruction succeeds, the data will have been transferred to the SBALs of the inbound queue of the target LPAR. In contrast, if the execution of the SIGA instruction fails, condition codes can be inspected to allow the issuer, be it an application program or the central processor, to interrogate the outcome of the SIGA instruction.
Occasions will arise, however, where the target LPAR does not have an available SBAL queued in the inbound queue to receive inbound data. Inasmuch as the SIGA instruction is synchronous in nature, though, the QDIO hardware cannot suspend operation of the SIGA instruction until an SBAL can be queued by the central processor. Conventional QDIO designs provide for retrying the SIGA operation in this circumstance. Specifically, the central processor can ignore the out-of-storage condition of the inbound queue and either can allow an associated stack to drop, or the central processor can retransmit the data packets. Alternatively, the central processor can retry the SIGA operation one or more times over a period of time.
Both conventional retry options can be expensive in terms of processor cycles and can lack precision. Moreover, both retry options can provide for an unpredictable and unreliable interface. Internal interfaces ought to provide a reliable and not unreliable transport. Since traditional “network” errors are not a factor in the case of LPARs, the iQDIO architecture also should be much more reliable. Accordingly, there has arisen a need for an effective retry method for use in an iQDIO architecture.